Migration, consolidation, virtualization, and cloudification are some of the information technology (IT) transformation tasks, particularly involved with the current era of cost savings and green data centers. In this disclosure, those and the like tasks are collectively referred to as “migration.” A task in migration includes the discovery of dependencies or affinities, i.e., what components (servers, applications, application modules, databases, etc.) interact with what other components via the network.
In migrating components to a target environment with different addresses (such as IP addresses or domain names in the context of the Domain Name Service) and possibly a different network topology, the firewall configurations in the target environment need to be set such that all components that need to interact can still interact, but without opening too many unnecessary communication paths. “Firewall reconfiguration”, for instance, refers to reconfiguring or setting of firewall parameters in the target environment so that the components in the target environment after the migration can still interact. Firewall reconfiguration is currently done manually, often even without access to a detailed representation of the dependencies in the source environment.
Migrating applications to a new network should still allow the interactions to happen seamlessly, for example, enable the new firewalls or the like to allow the migrated applications to function as before.
Wrong firewall reconfiguration in the sense of a missing “allow” rule is a significant source of errors that show up later in end-to-end testing and are difficult to identify and fix, thus contributing to long migration schedules and high migration costs. For those reasons, many enterprises continue to shy away from migrations. Vice versa, making too many “allow” rules in the target environment might open the target environment to more types of attacks than necessary and than what was possible in the source environment.